1) If there is a bad glitch with a particular mod, you should talk to the mod creator and make sure they use the latest editor test patch. Since editor version D26 there are limits on the number of triangles in the second LOD (shadow LOD). Often mod creators have been lazy and instead of spending a short time to make a low poly shadow mesh, they instead made a direct copy of the main mesh. The recent editor test patches impose limits on that.
2) In the development version which we are all waiting for, there is delayed texture loading, so the car is initially created, but the textures load over subsequent graphical frames, instead of loading them all at once.
Thanks for the report. That crash isn't in the LFS.exe module so I can't narrow it down to the region of code that caused it. There are some undocumented crash fixes in the test patches, related to mods that have not yet loaded, so I hope maybe one of those fixes is the reason why the test patches aren't crashing.
Of course, the best racing is with real players. But they aren't always available when you want to race, and some people (sometimes) enjoy racing alone without the need to interact and cooperate with other people. So there will always be a need for AI drivers.
I've done some AI improvements in the last few test patches. You can read the descriptions here, see the notes for D37 to D40: https://www.lfs.net/forum/thread/102117
Feedback will be welcome, on the test patch thread. There are definitely some improvements but please let me know if I've made something worse by mistake. AI is pretty tricky to get right!
Thanks for that, I was able to reproduce it in a deterministic game setup. It turns out a bit of an obscure bug that could sometimes cause AI to hit the brakes if they are slightly faster than another other car, but the other car is accelerating.
It seems like an old bug that has been there forever, but maybe it became slightly more likely to happen in the latest patch. It wouldn't be limited to the start grid, so maybe there will be some times out on the track when a car would have braked momentarily for no apparent reason.
I'll release another test patch with this and probably another couple of updates either today or tomorrow.
EDIT: Unfortunately, this bug fix hasn't magically fixed the issue where a faster car gets stupidly stuck behind a slower car, all the way down a long straight.
D39 is now available with AI improvements. I recommend deleting the bike AI paths created in test patches D37 or D38 (since 11 September) as the bikes now have a narrower theoretical width. Existing paths will still work but new ones will allow the bikes to use a bit more of the track.
Bike AI:
Smaller assumed width (closer passing distance / better lines)
For best results, delete bike knw files from data\knw folder
(generated since 11 September in D37 or D38 test patches)
Overtaking AI: (all vehicles)
Various improvements to improve the overtaking decisions
There should be fewer dangerous overtakes in braking zones
Thanks for the feedback. I've released D38 with three changes to much improve the mass pileup issue.
AI should be less likely to try passing in braking zones
FIX: AI can now reset if in contact with a stationary vehicle
FIX: AI will not cut engine after 40 seconds waiting to reset
I hope it doesn't break anything! The 'FIX' items are easy to test but it's a lot harder for me to test and confirm the results of the passing improvement. I think they make fewer bad passes because they take into account their predicted lower speed because they are braking. Although I did still see a pass that was obviously a bad idea, so I'm not certain how much better it is.
EDIT: The fix "AI can now reset if in contact with a stationary vehicle" will not work if you are online, until new servers are released. That is because when online the "safe to reset" decision is made on the server.
I've done some AI updates and copied them into the D37 test patch.
AI can now drive objects (do nothing) or motorbikes (slowly)
EDIT: AI can also enter in configs with no path, but will just sit there.
This started from a request to allow the AI to use objects, so they can be tested offline. It's an old thing on my list. But it seemed best to allow all mods, not just objects. That means motorbikes had to be supported. Well, a "few hours" turned into quite a few days. So, sorry about the delay to other things. I have stopped short of trying to really get the best out of them. There are issues with the tyre physics and the bikes actually work better in the new tyre physics.
If you are interested in object mods or bikes, please have a go with the new AI code. It was hard to get them to go round at all on bikes, then there was quite a struggle to get them to leave or enter pits. Hopefully I haven't broken anything for the other AI!
EDIT: Some bikes are too wobbly and crash too often, but maybe you can let me know if enough bikes seem to ride OK at enough tracks.
I know some people will be upset at another delay, but this is an important part of finishing the mods system. Other people will have fun using these AI updates. I've still got the incompatible updates including wheel rim improvements to release in the next few days.
I know it's a bit laborious but I just want to make sure you know, you can use a CAR.lfs script to implement a /ff command for that vehicle. E.g. XRT.lfs in the script folder. You can write such scripts for mods too, with names like SKINID.lfs
I can't remember, but think I asked Victor for that some time ago. I don't know if it applies to these test patches or not. Maybe you can try, and if you can't, then let me know and I'll ask Victor?
A solution is now available. Sorry you had to wait so long.
I was working on something else related to gear shifts so I decided to focus on this specific issue today. I have now made it so that a "fake key press" initiated by a mouse wheel move now lasts for 100ms.
Previously it was as if the key was only pressed for one physics frame, which was not long enough to do the gearshift. Although the ignition cut happened (as you said) the drive train did not become unloaded during that single physics frame, to allow the shift to take place.
The solution seems very reliable to me. I hope you can test it when convenient.
The long vehicle falls through because it is long and there are too many objects in the vicinity. It's not because the wheels are big. The objects in vicinity are calculated by an inefficient method that is better in the development version of LFS.
In your version, it runs out of slots for physical objects. I've increased the maximum from 64 to 80 and the long vehicle can now drive in that place you described.
About the bridge, it still does fall through the ground at that point behind the WE pits. There are simply too many objects nearby. It's because the assumptions that the physics system is based on do not apply to such large moving objects.
At this point, I think it's best to leave it at that. Longer vehicles are less likely to fall through the ground now because of the increase from 64 to 80. I don't want to increase the limit much as there might be consequences I don't want to deal with.
---
About your other suggestion, it has been on a list for a long time to allow AI to "drive" objects (i.e. sit there not doing anything). I enabled that yesterday. But so far they aren't allowed in to configurations without a path (same as other AI). But that restriction makes no sense for objects as they can't follow a path anyway. I'm thinking that the solution should be that AI, driving any mod, should be allowed in configs without a path (but simply sit there not doing anything as they have no idea where to drive).
This would allow people to test custom layouts more easily, for example start grids could be tested properly by AI drivers, even if they don't drive anywhere. I'm not seeing any issues with this, as long as LFS will somehow tell the user that the AI can't drive a car on that track.
I'll have a go today to see if I can allow AI on all configurations. It's not high priority but would be useful if I can do it easily. I hope it doesn't lead to any further complications I haven't thought of.
As many of you know, I am trying to get to a full version release so that all racers get the benefit of the recent updates, which I won't list here (you can read the first post of the editor test patch thread).
I noticed that some people, who want better looking wheels, have been using workarounds for deficiencies in the wheel rim system. So I really had to sort that out, even if it delays this full version release and my subsequent work on tyre physics. Sorry to the physics purists but I can't really leave the editor with such glaring issues. Wheel designs are very important and some people are putting a lot of effort into their mods. It's not good to have more and more mods with workarounds for a system that needs changing. So I have worked for a few weeks on this system for rim and wheel graphics.
Here I will list the updates and then post a few pictures:
Wheel rims:
Rim can now be fully edited, there are no fixed surfaces Rim no longer blends seamlessly into the wheels without an edge Allows more design flexibility for alloy wheels and steel wheels Removed: edge extra width / lip depth / inner depth / black inner A simple alloy style edge is automatically added to existing rims Option to allow separate wheel style (rim/spokes) for front & rear Tyre vs rim guide in the vehicle editor helps set correct rim size Rim has 60 segments around instead of 30 (tyres still 30 around) Rim guide in rim editor shows regions that should be covered The colour at the bottom of the list can now be deleted 3D view visible in rim editor can now be rotated
Wheel lighting:
New ambient lighting system for wheels and spokes Separate options for front and rear "concealed wheels" lighting The new lighting system replaces the old 'rim shade' option Auto repair removes the Dx/Ex darker colours from rim
The new lighting system affects both the rim and spoke objects. The lighting at each vertex depends on its depth in the wheel and the direction it faces, by an approximation system that is also affected by the "concealed wheels" setting (that makes it darker on the inside).
I think this ambient lighting should also be applied to any 'brake' or 'hub' objects that are found, because they are also within the wheel cylinder. But let me know if there are other uses for such objects, that mean the new lighting shouldn't be applied to them.
More notes:
I would advise mod makers not to use rim workarounds for now, as the auto repair is likely to affect the look of your work in the rim flange area. It's probably best to go along with the default LFS rims at the moment. If you do use workarounds, please be ready to fix your mods as soon as the update is released.
The update will be incompatible. Not for physical reasons, but simply because the file format is updated. That means, old LFS will no longer be able to load mods saved with the new version. There will be a test patch that can load the newly saved mods, of course. I will start a few test servers for people to test their mods, during the short period of time when the incompatible test patch is out and we are in final testing before the official update. I hope that period will be only around two weeks, to allow enough time for testing.
You will need to say which wheel you are using and which version of the drivers you are using, which version of Windows, etc. Maybe someone has come across the same problem and can help you.
LFS force feedback works properly with most wheels, so this is most likely a problem on your computer, not an LFS bug.
Or maybe I misunderstood you... you say something about changing wheels? Maybe there is a specific sequence of events that causes the problem. Then maybe you need to report in the bugs section. Either way, please be very detailed in your explanation, so we have some idea how to help you.
But as Flame says, this is not related to the test patch, so we do not discuss it here.
As you can see, particularly on the Editor Test Patch thread, I have made a huge number of improvements for the mod support. I find it a great thing that LFS is a way for people to be creative, and the mods system is a massive new part of that. It was very "new" indeed when released (basically a bunch of dev editors brushed up a bit) which is why there have been so many issues to sort out.
In the past months, while I have been doing these, Eric was at first finishing South City, which took a lot longer than he anticipated. Filling those holes is not easy, and he likes to fill them just as people would actually "fill the holes" when building a real city. I received an update recently and tested it, reported a bunch of issues and he fixed those. We find the completion level very good now, basically good enough for public testing when we can get the full version together. He is now working on the Kyoto improvements. As you may know from the official progress reports, that was never finished before Eric moved onto the South City, that turned into an epic development and massive expansion.
On my side, I'm trying to finish test patch things so that I can finally complete the tyre physics. In fact my current focus is on wheels, both in the development and public version. In the public version there should be a graphical update for wheels in the next few days, to go along with the many updates there have been for mods. Again, please read the test patch threads to know what I'm talking about.
There is also other work I do, that you never see, such as updates for the track editor. Suppose Eric is doing a task and finds he has to do something in a laborious or repetitive way and one of us thinks of a new editor function that could help him achieve certain tasks more quickly, then I always want to stop whatever else I was doing and work on the track editor for a few days.
I'm trying to get to an official release so my focus can then be entirely on the tyre physics in the development version. It has taken me much longer than expected to complete this round of test patches as there were so many unfinished things in the mods system. When I see creators, working hard and having to use workarounds for issues, I feel a great responsibility to get that issue sorted out.
Of course, the priorities I attach to various tasks, will not be the same as someone else's priority. We all have different priorities, so there's not a person in the world who could agree with all my choice of tasks to work on. But I must work on what I feel is important. Actually I find it a huge mental effort to complete these tasks, and that's why I need to follow the inspiration. Sometimes I'm awake at night working out how to do something, then experimenting and testing, it's a lot of work.
It takes a long time, but there is always progress.
Test patch D32 now has support for the new hub objects that can be added in Editor D39.
Also:
Regional downloads (for mods) can be disabled by a new Misc Option
A yellow redirect message is shown the 1st time you are redirected
Hold CTRL in Garage: Mods button becomes Test (direct to Test mode)
Opening mods screen is prevented if a rating request is in progress
FIX: Crash enabling filter in List of Hosts after all were disabled
FIX: Small camera movement on releasing LMB after 2-button rotation
The mappings *should* be retained when merging a subobject (since at least D23) but I see that there are cases when it goes wrong. For instance I made this LX4 test with a dash mapping in a rotated subobject. When I merge the subobject, the rotated dash mapping is preserved correctly. But I do notice a problem with mapping "C1_hdLB" which you can see as a wrong mapping on part of the painted outer of the subobject after the merge.
I don't yet know why it went wrong but I've made a note to look.
I agree that should be in the incompatible update. My current plan is to add a few incompatible changes for the official version, which will benefit from being incompatible due to a new InSim feature that can set individual players' handicaps. Most features are already coded and shouldn't need much testing. We don't want a long period when test patches are incompatible, it's not worth it at the moment. But such simple updates are worth including.
I already had on my list to increase F1 max engine size to 5L as I read one of the early F1 limits was 4.5L. I guess bike could go up to 3L and I'm not sure about "formula" - maybe 8L like the GT class?
Nice dashboard, thanks for the result image and testing!
Please can you remove your suggestions and instead put them on the appropriate thread in the suggestions forum?
It's really impossible for me to follow things and retain my sanity if random suggestions are all over the place and the test patch thread is spammed up with off topic.
This thread is for discussions about the current editor test patch. Off topic suggestions here will be ignored.
By the way, did you get any better results with the bus mirrored texture?
Ability to set colours instead of using the system colours
Set background colour without supplying a backing texture
Some new options for road and formula clocks
The colour selections and some updates for formula clocks are nearly ready but I want to test thoroughly and finish a couple of options. So I should release an updated test patch and editor tomorrow instead of this evening.